I don't really trust string.GetHashCode, I doubt it was designed with strong collision resistance in mind.

If a true cryptographic hash like sha is too expensive, can you maybe at least use a specialised one like murmurHash?

(Sorry, can't sleep)

I think what's worth thinking about is if this is a scenario where strong collision resistance is important. For example, in each cache here, the key varies:

• AreSimilarForParsing uses the file name as the key
• AreSameForParsing uses the file name, FSharpParsingOptions (also contains source files, so this needs to be thought about), and (now) the hash of the source file as the key

And so on. All current keys are an aggregate of some information. Given that, does it make sense to use a cryptographically strong hash function? Is the Birthday Problem applicable for IDE tooling? Would doing so be meaningful perf-wise? Not entirely sure how to answer each question, but we definitely do want to move away from storing the whole source text if we don't actually need it.

I think I often sound too negative. Hashes are awesome and this pr is great.

String.GetHashCode is 32 bytes, so 4 giga possibilities.

Really large source files can be many kB to maybe even MB if they are auto-generated?

I was never that good in statistics, and am just talking out of my behind because I'm bored. But that's a few magnitudes too few for me to be comfortable ;D

But I would reverse that question: is there any reason NOT to use a strong hash?

Typechecking is probably so expensive that running a sha256 over the source wouldn't be noticeable.

And if it is, there is still murmur3, which is a fast, specialised, 128 bit hash.
Heck, you could also use md5 (also 128 bit)

So I'm pretty sure my stats needs some work (it's been a while!), but here's a quick calculation in the awesome Fable repl. So for 10k files, we could see a ~1.1% chance of a collision with string's GetHashCode, assuming we only use that as a key for a cache. Given that we aggregate additional information I think it's fine, but I wouldn't take that as gospel 🙂

That said, I certainly don't see anything wrong with a stronger hash function if the perf isn't a problem. We'd have to measure that, but if it's negligible then I think something like MD5 is fine. I'd much rather use something in the BCL than having to hand-code some F# implementation of something in here.

So, second commit is uhhh...a lot more. But this addresses all sources of source files being used as keys in the caches. Let me make sure this PR is marked as WIP so we don't ever accidentally pull it before really vetting the approach.

Typechecking is probably so expensive that running a sha256 over the source wouldn't be noticeable.
And if it is, there is still murmur3, which is a fast, specialised, 128 bit hash. Heck, you could also use md5 (also 128 bit)

.NET MD5 and SHA-1 implementations have approximately same performance, SHA-256/384/512 are way slower, so I'd use SHA-1 or murmur3, if it's fast.

@cartermp Is the second commit necessary, what are we saving by hashing source file names?

Ah, yeah they're just the path+names (even though they're not named that way). I'll be rid of the second commit.

Closing this as the PR, #6001, makes source text equality abstract for caching. If you are using the string implementation of ISourceText , it will do the direct string compare. But for VS, we have an implementation of ISourceText's ContentEquals to be Roslyn's SourceText's ContentEquals which does the right thing already: http://source.roslyn.io/#Microsoft.CodeAnalysis/Text/SourceText.cs,dc290adccf6f9ba7
Other IDEs will be recommended to implement their own ISourceText so they are in charge of the efficiency there; but I will always recommend them to just take a dependency Microsoft.CodeAnalysis and implement ISourceText using Roslyn's SourceText.

A path forward for caching will be interesting. Ideally we might want to use an int based on time to determine file changes.